Date: Wed, 30 Mar 94 04:30:23 PST From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #87 To: Ham-Digital Ham-Digital Digest Wed, 30 Mar 94 Volume 94 : Issue 87 Today's Topics: DGMSK? HF Throughput Revisited mailgateway Packet Radio <--> Internet Newbie Q: obtaining IP address NTS traffic on packet (2 msgs) Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: 28 Mar 94 18:16:00 GMT From: dog.ee.lbl.gov!agate!library.ucla.edu!news.mic.ucla.edu!unixg.ubc.ca!nntp.cs.ubc.ca!utcsri!newsflash.concordia.ca!canopus.cc.umanitoba.ca!mona.muug.mb.ca!mwcsinc!bill.@ihnp4.ucsd.edu Subject: DGMSK? To: ham-digital@ucsd.edu ˜@TO :dreamer@lhaven.UUmh.Ab.Ca N -> What kinds of high speed packet data are allowed? Are there -> regulations on what kind of data modulation is employed for packet -> operation? -> -> A whole bunch of old 9600bps data radios have become -> available......they do something like DGMSK or letters to that -> effect....and immediately its said that's illegal. because its not -> AFSK...and the units don't do AX.25. Rubbish. Read RIC 24 and RIC 25. You can't use a secret code - any coding done to improve information handling is OK, if you're using something unusual you should be prepared to explain how it works to the local DOC. You must faithfully observe the bandwidth limitiations in the table. You must of course not use frequencies below 50 MHZ if you don't know how to send Morse. Aside from that, there is no restriction on what you can use ( in Canada) for amateur radio data. The US rules are written more for the benefit of lawyers and hams but their problems need not concern you; and from what I've read the only restrictions they have is that 3rd party traffic handled by an unattended station must use AX.25 - they also have some baud rate restrictions. Local rules only, don't apply to you, have fun. Get a G3RUH or K9NG modem from TAPR, couple of old radios, and leave 1200 in the dust. Bill ve4stw ---- Muddy Waters Computer Society Inc. Winnipeg, Manitoba, Canada (204)943-6507,08,09 (204)942-0227 (204)956-4997 (all nodes USR 16.8K D/S) ------------------------------ Date: 29 Mar 94 18:32:55 GMT From: agate!howland.reston.ans.net!pipex!sunic!psinntp!psinntp!arrl.org!jbloom@ucbvax.berkeley.edu Subject: HF Throughput Revisited To: ham-digital@ucsd.edu Rick Whiting (Rick_Whiting@ATK.COM) wrote: : surprised CLOVER did not do better.] Based on this and other : published data, the throughput (CPS) for various protocols on HF : would appear to line up as follows: AX.25 Packet 4, AMTOR ARQ 5, : RTTY 6, PacTOR 9-10, CLOVER 16, and G-TOR 24. : By the way, I don't think the Kantronics KAM used in Westhuizen's : tests implemented hardware ADC Memory ARQ. Furthermore, the No, it doesn't. But it's debatable how much difference that makes. Kantronics says they haven't been able to measure a difference, although they also say their testing hasn't been extensive on this point. : various throughput data cited above were not taken by the same : experimenters under similar conditions, etc. Right, which makes the comparison very much apples and oranges. Given the massive variations in HF conditions fram band to band, location to location, season to season and, often, minute to minute, you need a lot more data than this to make any useful comparisons! Plus, three of these protocols are adaptive. (Clover is bit-rate adaptive, PACTOR and G-TOR are bit- and symbol-rate adaptive.) Thus it is crucial to factor in the channel conditions, since throughput will vary, probably non- monotonically, with channel degradations of various types and combinations. That way, you can determine which protocols favor which propagation conditions, and by how much. Or you can factor *out* the channel conditions by taking a lot of data that span the (reasonable) range of channel conditions to get a "figure of merit" for each protocol. But since none of that has been done--or published, at any rate--the conclusions you can draw from the given data are nonexistant. And the term "throughput" itself is a bit slippery here. How do you count the characters that RTTY or AMTOR "receive" but which are not the characters that were sent? Seems unfair to the protocols that provide data integrity to count garbled characters the same. Bottom line: comparing error-free protocols with RTTY/AMTOR is comparing not just apples and oranges, but two entirely different food groups! That said, there is plenty of evidence, both analytical and empirical, that suggests that any non-adaptive, non-FEC protocol is going to perform worse on HF, in general, than an adaptive protocol with FEC. Plus, I suggest that any protocol that allows undetected errors in reception is a nonstarter for serious HF communications in the 1990s. (Although they are fun to play with, and I certainly don't discount that.) Taking those two factors together, I suggest that the protocols whose throughput is of interest are PACTOR, CLOVER and G-TOR, in no particular order. The others are suitable only for play. : Of course, there are many features that differentiate the different : protocols beside typical throughput, not the least of which is : throughput normalized to bandwidth, i.e., CPS per hertz. And the Yes, and isn't it interesting that the one with the widest bandwidth supports the lowest throughput? (Even though the data above isn't particularly useful, I feel confident in saying that any test under conditions other than excellent will show AX.25 to be a loser.) -- Jon Bloom KE3Z jbloom@arrl.org ------------------------------ Date: Mon, 28 Mar 94 06:56:18 MST From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!cs.utexas.edu!asuvax!ennews!stat!david@network.ucsd.edu Subject: mailgateway Packet Radio <--> Internet To: ham-digital@ucsd.edu > > I have read in the newsgroup rec.radio... > > in Amerika you have a mailgateway between Packet-Radio > > and Internet. How to Use the WB7TPY Packet <-> Internet Gateway First, some brief operational notes: (1) Messages must not contain any foul language, or commercial purpose. (2) Messages can only be sent to countries that the United States has a third-party agreement. All others will be destroyed. (3) Messages from the internet should be less then 5K in length. No files should be sent. (4) If you have questions, please do not hesitate to contact me either on packet radio: WB7TPY@WB7TPY.AZ.USA.NA -or- Internet : david@stat.com (5) Have fun. Use the gateway as much as you like. That is what it is there for. ------ From Internet to Packet ------ Send mail to the internet address of: gate@wb7tpy.ampr.org The first line of text must contain a full packet address, preceded with the word "Packet:" For example, mail to my packet address, would have the first line of text; Packet: wb7tpy@wb7tpy.az.usa.na ** NOTE: this line MUST be left justified. ------ From Packet to Internet ------ Send as private mail (never a bulletin) to the packet address of: gate@wb7tpy.az.usa.na The first line of text must contain a full domained internet address, proceeded with the word "Internet:" For example, mail to my internet address, would have the first line of text; Internet: david@stat.com --- Editor, HICNet Medical Newsletter Internet: david@stat.com FAX: +1 (602) 451-1165 Bitnet : ATW1H@ASUACAD ------------------------------ Date: 30 Mar 94 00:40:39 GMT From: dog.ee.lbl.gov!agate!msuinfo!cravitma@ucbvax.berkeley.edu Subject: Newbie Q: obtaining IP address To: ham-digital@ucsd.edu Apologies for the Newbie question, but... I am thinking about trying to set up NOS on the Club machine here at MSU. I think I can figure out how to get the software set up, but I have three questions: 1. Where do I get an IP address for our machine? 2. Where do I get a host file so that our machine knows about others on the net? 3. How do I propagate our IP address and hostname so that other systems know about it and where it is on the net? Thanks for any help. Responses via email are fine. /Matthew -- Matthew Cravit, N9VWG | All opinions expressed here are Michigan State University | my own. I don't speak for MSU E-Mail: cravitma@cps.msu.ed | and they don't speak for me. GO/CS -d+@ -p+ c++ !l u+(++) e+(*) s/+ n+(---) h+ f+ !g w+(+++) t++@ r(+) y? ------------------------------ Date: Tue, 29 Mar 1994 15:01:46 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!emory!nntp.msstate.edu!olivea!news.bu.edu!att-in!att-out!cbnewsh!ostroy@network.ucsd.edu Subject: NTS traffic on packet To: ham-digital@ucsd.edu Here's my two cents on a subject near and dear to my heart. Tod|> I am advised by local packet network managers and the local NTS Tod|> representatives that NTS traffic fares poorly on the packet network. The Tod|> problem is one of "culture" Tod|> The traffic culture was built around HF operations - originaly spark, then Tod|> cw , then voice and cw. When digital modes appeared, particularly AMTOR, Tod|> the NTS began to incoporate that mode for traffic. The traffic culture is Tod|> based upon one person handing traffic to another and the second person Tod|> agreeing to forward or deliver the traffic. The Q-signals reflect this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That's the key. in the old NTS, the recipient, by virtue of taking traffic, agrees to "forward or deliver" . A destination bbs, by contrast, has no obligation to forward or deliver. It simply waits for someone to "come and get it". It could wait forever. Hank>It is not "sent to a callsign", nor is it "placed in a file", it is sent Hank>to a zipcode, and is then picked up and delivered by *any* NTS person who ^^^^^^^^^^^^^^^^^^^^^^^ picked up by who? There are not that many people interested in picking up messages off a bbs and delivering them to the general public. Hank>wishes to do so. If any NTS message is "stuck" at some BBS, the problem Hank>lies with the NTS organization. One needs to think of the packet BBS system Hank>just like any other transport system. It needs to be serviced. Very true, but in reality, both Tod and Hank have said the same thing. Although the mechanism is there to move traffic on packet, the culture is not. Tod|> Most BBS operators implore those who check in to look at the accumulation Tod|> of NTS messages and accept one or more that they are willing to relay or Tod|> deliver. The problem is that there is not a habit pattern or culture Tod|> that has grown up within the packet community to accept such activity as Tod|> something of interest. In some cases, the persons checking in may not have Tod|> HF priviledges that permit them to off-load the messages to the local Tod|> traffic nets. Hank>This is an NTS problem, not a packet network problem. Hank>Why would one offload NTS traffic onto HF? This is exactly what the BBS Hank>system is good at; moving bunches of traffic from point A to point B Hank>without error for any user who wishes to use it. In my area, the vast majority of traffic which is removed from the bbs' is brought to a 2meter or 80/75meter net for delivery. This is because there are just not enough interested message deliverers to cover an entire section or state. Hank, the problem is that messages are not sent to a specific "user" at the receiving end. They are broadcast. Messages sent to some destinations have about as much chance for success as a CQ on 10 meters at the sunspot nadir. In the old NTS, all messages are handed to a specific user, the next person in the pipeline, until the last person is reached. Tod|> In summary, this is an interesting situation which perhaps offers an Tod|> opportunity for public service. If such a culture were developed, it would Tod|> be in place ready to go in the event of an emergency. Regrettably, to date Tod|> the right ingredients have not come together. Hank>The opportunity has been there for ten years now. The BBS system has Hank>worked in the same way with respect to NTS traffic since at least late Hank>1984. NTS has failed totally to take advantage of the resource available to Hank>them, at least in most areas of the country. NTS must understand that the Hank>average BBS sysop is *not* part of NTS, and has *no* particular interest in Hank>NTS messages per se. These messages are treated like any other traffic; Hank>moved to their destination by the quickest method possible. They key thing Hank>that NTS *must* do to make use of the network is to assign liason staff to ^^^^^^^^^^^^^ a great idea ...IF you can find enough interested people. Hank>the network. This has been done since 1986 in New England, and it works Hank>fairly well. Speaking for the area in which I now live, NTS folks are Frankly, if your sole traffic-handling activity is just picking messages off a bbs that you can deliver toll-free, you are going to get bored real quickly. The NTS "culture" has been built for years around participation in the pipeline, as an integral part of it. The packet bbs system has taken away the pipeline from the NTS'er and left nothing but simple unchallenging user interfaces at either end. No wonder NTS'ers are not interested. It's going to take a long time to develop a culture of message deliverers, as opposed to traffic network operators. (By the way, I participate in both facets of the hobby, lest you suspect bias.) -- Dan Ostroy - K2UL - AT&T Bell Labs, Holmdel, NJ USA 908-949-5922 ostroy@cbnewsh.att.com ------------------------------ Date: Tue, 29 Mar 94 19:06:51 GMT From: netcomsv!netcomsv!skyld!jangus@decwrl.dec.com Subject: NTS traffic on packet To: ham-digital@ucsd.edu In article <2n9j6k$db9@hp-col.col.hp.com> jms@col.hp.com writes: > This reply is directed to anyone who is taking part in this discussion. > > The problems I see with the end delivery of packet nts traffic are: > > 2. Some BBS systems do not allow a person to 'kill' a message once > it's been read for delivery. I WILL NOT deliver traffic from > such a board as it's embarrassing to attempt delivery when > someone else has already done so. JNOS (wg7j main author) allows anyone to kill mail in an area with NTS prefacing it. (Areas as opposed to listing by topic) So there are three catagories of areas now on my system, private (you have to be that person to read/kill) public (anyone can read, but sysop only to kill) and NTS (anyone can read and then kill). > So, can present BBs software be configured to forward nts traffic > to a given station, preferably re-address it to that Amateur's > call sign so they know there is messages waiting? Can it be set > up to send it to a different person each day, with maybe a different > person on odd or even weeks (don't want to leave out anyone who > wants to play)? A simple entry in the alias file will forward to whomever. so if I alias 90505 to kf6pu@wb6ymh.#soca first the alias file redirects it to kf6pu, the my rewrite file queues it up for delivery to the wb6ymh bbs. > BTW, thanks to all the BBS sysops out there that keep the boards > up and running. I know it's a big job and a lot of work. It is, but it is one of the ways to return something to the hobby. I'll leave it to some of our other members to do the take-take-take routine. 73 es GM from Jeff Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NOAM | "You have a flair for adding Internet: jangus@skyld.grendel.com | a fanciful dimension to any US Mail: PO Box 4425 Carson, CA 90749 | story." Phone: 1 (310) 324-6080 | Peking Noodle Co. ------------------------------ Date: 29 Mar 94 16:26:10 GMT From: agate!howland.reston.ans.net!europa.eng.gtefsd.com!emory!wa4mei!ke4zv!gary@ucbvax.berkeley.edu To: ham-digital@ucsd.edu References , , Reply-To : gary@ke4zv.atl.ga.us (Gary Coffman) Subject : Re: NTS Only BBS? (was Re: [REPOST] NTS Traffic on Packet) In article gganderson@augustana.edu (Kevin Anderson -7325) writes: >(2) I how much time, effort, and cost is involved in running a BBS? > >I ask not to point any fingers, but because I can't fathom what >the costs would be. I can think of there being the expense for >a good antenna, a reasonable 2m rig (50 watts?), a reasonably >fast computer (486 of some flavor) with a decent size hard disk, Gad! What do you think a packet BBS is, a major internet node on T1 trunks? An original IBM AT (8 MHz 286 with a 20 Mb hard disk) is beaucoup plenty computer to deal with the 1200 baud half duplex demands of VHF packet, or the 300 baud demands of HF packet. The main thing the computer needs is *patience*, and machines, even old machines, are good at that. What you do need is good radio equipment, excellent antennas, and in the case of VHF a very good high site for user access and forwarding. Likely you'll have several radios on several frequencies for user traffic and BBS to BBS forwarding. >that this power-hungry computer (400 VA watts?) would be running >24 hours a day, your time and effort in seeing that the computer >and radio keep running. I suspect MUCH IS already being given >by BBS operators as a service, but I'm just curious of the >accounting. The major cost of operating a full service BBS is *time*. It takes hours a day to manage the system and deal with naive users. There are routing databases to maintain, rewrite files to update, manual rerouting of naive user Email attempts, etc, etc, etc. Many Sysops keep spare radios and antennas, and spare computers, in order to maintain service in the event of downtime due to equipment failure. The wear and tear on the radio equipment is considerably higher than what most amateur grade equipment was designed to withstand. Since it's 24 hr operation, good lightning protection is a must. Gary -- Gary Coffman KE4ZV | You make it, | gatech!wa4mei!ke4zv!gary Destructive Testing Systems | we break it. | uunet!rsiatl!ke4zv!gary 534 Shannon Way | Guaranteed! | emory!kd4nc!ke4zv!gary Lawrenceville, GA 30244 | | ------------------------------ Date: Mon, 28 Mar 1994 17:17:42 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!portal.com!portal!combdyn!lawrence@network.ucsd.edu To: ham-digital@ucsd.edu References <1994Mar23.180631.11120@mnemosyne.cs.du.edu>, , <1994Mar26.183922.28611@mnemosyne.cs.du.edu> Subject : Re: KPC-3 and TCPIP In article <1994Mar26.183922.28611@mnemosyne.cs.du.edu> nburnett@nyx10.cs.du.edu (Nathan C. Burnett - N8MBK) writes: >dts@world.std.com (Daniel T Senie) writes: > > >>Could you elaborate on this last comment? Obviously the KPC-3 is 1200 only, >>but it has software (open squelch) DCD available (just issue a command) and >>has KISS mode. Did you experience problems with either of these things? > >iYes the KPC-3 does have KISS mode however I prefer to run a KISS only EPROM >so I don't have to put it in KISS everytime I want to use it. Also the DCD >detection provided by the TAPR DCD mod is IMHO far superior to that of the >KPC-3's software DCD. > Hmm, when I had the KPC-3 on my system....I put it into KISS mode, and left it that way....never had to tell it to go into KISS mode again during use. I'm now running a DRSI DPK-2 and a AEA PK88, both with the normal ROMs...I put them into KISS using a terminal...and I have never taken them out of KISS. I can't comment on the superiority of the TAPR DCD mod to the software DCD, I ordered one a few weeks ago, and it hasn't arrived yet. But, I'll say the software DCD is better than nothing. The squelch on one radio likes to walk... the other day it tightened up so I couldn't hear anything.....so the system just kept polling every second messing up the network. The week before, the squelch opened up and my system couldn't transmit...... -- WORK: lawrence@combdyn.com | PHONE 403 529 2162 | FAX 529 2516 | VE6LKC HOME: dreamer@lhaven.uumh.ab.ca | 403 526 6019 | 529 5102 | VE6PAQ ---------------------------------------------------------------------------- Praxis BBS - 529 1610 | CYSNET BBS - 526 4304 | Lunatic Haven BBS - 526 6957 ---------------------------------------------------------------------------- disclamer = (working_for && !representing) + (Combustion Dynamics Ltd.); ------------------------------ End of Ham-Digital Digest V94 #87 ******************************